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The PPP AppleTalk Control Protocol (ATCP) 
Status of this Memo 


This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 


Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method of 
encapsulating Network Layer protocol information over point-to-point 
links. PPP also defines an extensible Link Control Protocol, and 
proposes a family of Network Control Protocols (NCPs) for 
establishing and configuring different network-layer protocols. 


This document defines the NCP for establishing and configuring the 
AppleTalk Protocol [3] over PPP. 


This memo is a joint effort of the AppleTalk-IP Working Group and the 
Point-to-Point Protocol Working Group of the Internet Engineering 
Task Force (IETF). Comments on this memo should be submitted to the 
ietf-ppp@ucdavis.edu mailing list. 
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1. Introduction 


PPP has three main components: 
1. A method for encapsulating datagrams over serial links. 


2. A Link Control Protocol (LCP) for establishing, configuring, 
and testing the data-link connection. 


3. A family of Network Control Protocols (NCPs) for establishing 
and configuring different network-layer protocols. 


In order to establish communications over a point-to-point link, each 
end of the PPP link must first send LCP packets to configure and test 
the data link. After the link has been established and optional 
facilities have been negotiated as needed by the LCP, PPP must send 
NCP packets to choose and configure one or more network-layer 
protocols. Once each of the chosen network-layer protocols has been 
configured, datagrams from each network-layer protocol can be sent 
over the link. 


The link will remain configured for communications until explicit LCP 
or NCP packets close the link down, or until some external event 
occurs (an inactivity timer expires or network administrator 
intervention). 


2. A PPP Network Control Protocol (NCP) for AppleTalk 


The AppleTalk Control Protocol (ATCP) is responsible for configuring, 
enabling, and disabling the AppleTalk protocol modules on both ends 
of the point-to-point link. ATCP uses the same packet exchange 
machanism as the Link Control Protocol (LCP). ATCP packets may not 
be exchanged until PPP has reached the Network-Layer Protocol phase. 
ATCP packets received before this phase is reached should be silently 
discarded. 


The AppleTalk Control Protocol is exactly the same as the Link 
Control Protocol [1] with the following exceptions: 


Frame Modifications 


The packet may utilize any modifications to the basic frame format 
which have been negotiated during the Link Establishment phase. 
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Data Link Layer Protocol Field 


Exactly one ATCP packet is encapsulated in the Information field 
of a PPP Data Link Layer frame where the Protocol field indicates 
type hex 8029 (AppleTalk Control Protocol). 


Code field 


Only Codes 1 through 7 (Configure-Request, Configure-Ack, 
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack 
and Code-Reject) are used. Other Codes should be treated as 
unrecognized and should result in Code-Rejects. 


Timeouts 


ATCP packets may not be exchanged until PPP has reached the 
Network-Layer Protocol phase. An implementation should be 
prepared to wait for Authentication and Link Quality Determination 
to finish before timing out waiting for a Configure-Ack or other 
response. It is suggested that an implementation give up only 
after user intervention or a configurable amount of time. 


Configuration Option Types 


ATCP has a distinct set of Configuration Options, which are 
defined below. 


2.1. Sending AppleTalk Datagrams 


Before any AppleTalk packets may be communicated, PPP must reach the 
Network-Layer Protocol phase, and the AppleTalk Control Protocol must 
reach the Opened state. 


Unless otherwise negotiated (via option 4), exactly one AppleTalk 
packet is encapsulated in the Information field of a PPP Data Link 
Layer frame where the Protocol field indicates type hex 0029 
(AppleTalk). 


Note that the negotiation of compression may imply the use of 
different encapsulation and hence different protocol fields. These 
different protocol fields imply packet types which are sub-protocols 
of the base AppleTalk NCP. 


An encapsulated AppleTalk packet begins with an extended DDP 
(Datagram Delivery Protocol) header -- also known as a Long DDP 


header. The maximum length of a DDP datagram is 599 octets. 


Since there is no standard method for fragmenting and reassembling 
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AppleTalk datagrams, it is required that PPP links supporting 
AppleTalk allow at least 599 octets in the information field of a 
data link layer frame. 


2.2. Half-Routers 


One model for routers in [3] is two remote AppleTalk routers linked 
as “half-routers" without a Node ID or Network number assigned to 
either side of the link. When acting as half-routers, the only 
effect on transported packets is that the hop count is incremented 
when it is received over the link. Routing updates received over a 
half-router link should also increment the hop count of routing table 
updates. 


As part of normal operation, AppleTalk will send RIMP Routing updates 
every 10 seconds. 


3. ATCP Configuration Options 


ATCP Configuration Options allow negotiation of desirable AppleTalk 
parameters. ATCP uses the same Configuration Option format defined 
for LCP [1], with a separate set of Options. 


The most up-to-date values of the ATCP Option Type field are 
specified in the most recent "Assigned Numbers" RFC [2]. Current 
values are assigned as follows: 


1 AppleTalk-Address 

2 Routing-Protocol 

3 Suppress-Broadcasts 

4 AT-Compression-Protocol 
5 RESERVED 

6 Server-information 

7 Zone-information 

8 Default-Router-Address 
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3.1. AppleTalk-Address 
Description 


This Configuration Option provides a way to negotiate the 
AppleTalk network and node number to be used on the local end of 
the link. It allows the sender of the Configure-Request to state 
which AppleTalk-address is desired, or to request that the peer 
provide the information. The peer can provide this information by 
NAKing the option, and returning a valid AppleTalk-address. 


If negotiation about the remote AppleTalk-address is required, and 
the peer did not provide the option in its Configure-Request, the 
option SHOULD be appended to a Configure-Nak. The value of the 
AppleTalk-address given must be acceptable as the remote 
AppleTalk-address, or indicate a request that the peer provide the 
information. 


By default, no AppleTalk address is assigned. A network or node 
number specified as zero in a Configure-Request shall be 
interpreted as requesting the remote end to specify a value via a 
Configure-Nak. A network or node number specified as zero in a 
Configure-Ack shall be interpreted as agreement that no value 
exists. 


An implementation which requires that no AppleTalk addresses be 
assigned (such as a intermediate system to intermediate system 
"half-routing") MUST Configure-Reject all AppleTalk-Address 
Configuration Options. 


An implementation which requires that AppleTalk addresses be 
assigned to it (such as a end system) MUST fail configuration if 
the remote side Configure-Rejects all AppleTalk-Address requests, 
or fails to provide a valid value. 


If this option is negotiated, the two sides MUST negotiate a 
common AppleTalk network number and two unique Appletalk node 
numbers. The network number MAY be zero but the Appletalk node 
numbers MUST be non-zero. Values selected for network and node 
numbers must adhere to the ranges defined in [3]. 


The AppleTalk protocol, phase 2, defines the concept of "extended" 
and "non-extended" networks. Extended networks can support a 
large number (hundreds) of nodes, and requires multiple network 
numbers and multiple zone names to be managed effectively. Non- 
extended networks can only support a small number of devices, and 
require only a single network number and zone name to be managed 
effectively. 
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If a PPP link transporting AppleTalk is assigned an AppleTalk 
address, it must have the "non-extended" characteristics as 
defined in [3]. 


The format of the network and node data is defined to be the same 
as the "AppleTalk address" in [3], chapter 3, "AppleTalk AARP 
packet formats on Ethernet and token ring". 


A summary of the AppleTalk-Address Configuration Option format is 
shown below. The fields are transmitted from left to right. 


0 f 2 3 
OL 2-3-4 S 6-7 890 12) 34S: 6 FB VD OL 23 49 4627 28 9 Od 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Length | Reserved | AT-Net 
Pott t- ttt pitt i titi ttt it iti titi tat titi titi to titi tat 
| AT-Net | AT-Node | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


Length 


Reserved 


This octet is reserved and MUST be set to zero on transmission and 
ignored on reception. 


AT-Net 
The two octet AT-Net is the desired local AppleTalk network number 
of the sender of the Configure-Request. This two octet quantity 
represents a 16 bit unsigned number sent "network byte order" 
(most significant octet first). 


AT-Node 


The one octet AT-Node is the desired local AppleTalk node ID of 
the sender of the Configure-Request. 
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3.2. Routing-—Protocol 
Description 


This Configuration Option provides a way to negotiate the use of a 
specific routing protocol. In particular, "half-routers" may want 
to exchange routing information using a protocol optimized for the 
PPP connection. By default, AppleTalk RTMP (Routing Table 
Maintenance Protocol) routing information is sent over the PPP 
connection. 


By default, AppleTalk RIMP routing information is sent over the 
PPP connection. 


A summary of the Routing-Protocol Configuration Option format is 
shown below. The fields are transmitted from left to right. 


0 1 2 3 
012345678901234567890123456789 021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


| Type | Length | Routing-Protocol 
+-+-+-+-+-+-+-+-+-+-+-+-+-+H++H++H+HHHHHHHHHH H 
| Data 


+-+-+-+-+ 


Type 


Routing-Protocol 


The Routing-Protocol field is two octets and indicates the type of 
Routing-Protocol desired. This two octet quantity represents a 16 
bit number sent "network byte order" (most significant octet 
first). 


Negotiation of some routing protocols implies that you will 
receive packet types which transport these protocols. 


For example, negotiating AppleTalk AURP to exchange routing 


information implies both sides will accept EDDP type packets, 
since this is the transport type used by AURP. 
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Initial values are assigned as follows: 


Value Protocol 
0 No routing information exchange 
1 AppleTalk RTMP is used to exchange routing information 
2 AppleTalk AURP is used to exchange routing information 
3 AppleTalk ABGP is used to exchange routing information 


Data 


The Data field is zero or more octets and contains additional data 
as determined by the routing protocol indicated in the Routing- 
Protocol field. 


None of the Routing-Protocol options defined here require 
additional data. 


3.3. Suppress-Broadcasts 
Description 


This Configuration Option provides a way to negotiate the 
suppression of AppleTalk broadcast datagrams which might otherwise 
use up limitted PPP bandwidth. This Configuration Option is used 
to inform the remote end that no AppleTalk broadcast datagrams of 
a given DDP type should be sent. 


This option is useful when negotiated by a single end system. It 
allows the local end system to request that broadcast packets 
generated on a remote network not be propagated across the PPP 
link. In the case of a single end system connected to a large 
network, this can be used to suppress regular NBP lookups 
generated by other end systems on the remote network. This will 
mean that protocols such as NBP can no longer be used to find 
network entities on the local system, but since the option 
configuration is asymmetric, it does not inhibit the local 
system’s ability to find network entities on the remote network. 


By default, no AppleTalk broadcast datagrams are suppressed. Note 
that this option may conflict with other options (such as Routing 
Protocol). If so, the Suppress-Broadcasts option takes 
precedence. 


A summary of the Suppress-Broadcasts Configuration Option format is 
shown below. The fields are transmitted from left to right. 
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0 d 2 3 
OL 253° 4 946. 7 8.9 OT -2 3 4S 67 8G OL 2 3 AN 6-7. 8 OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | DDP-Type 1 | DDP-Type 2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| etc... 
+-+-+-+-+ 


Type 


DDP-Types 


A vector of one or more single octet DDP type values, each of 
which are to be suppressed if sent to the broadcast address. 


If no data is present (the length = 2), all broadcast packets are 
to be suppressed, regardless of DDP type. 


3.4. AT-Compression-Protocol 
Description 
This Configuration Option provides a way to negotiate the use of a 
specific compression protocol. By default, compression is not 


enabled. 


A summary of the AT-Compression-Protocol Configuration Option format 
is shown below. The fields are transmitted from left to right. 


0 1 2 3 
OE 2? 3+ AM 9:06) B89 0 12 3) Ano 60 "EB Se OL 2 3 4s 168 T8829 Oi 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Length |  AT-Compression-Protocol 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++ 
| Data 

+-+-+-+-+ 


Type 


4 
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Length 
>= 4 

AT-Compression-Protocol 
The AT-Compression-Protocol field is two octets and indicates the 
compression protocol desired. Values for this field are always 
the same as the PPP Data Link Layer Protocol field values for that 
same compression protocol. 
The most up-to-date values of the AT-Compression-Protocol field 
are specified in the most recent "Assigned Numbers" RFC [2]. 
Current values are assigned as follows: 


Value (in hex) Protocol 


none defined 


Data 


The Data field is zero or more octets and contains additional data 
as determined by the particular compression protocol. 


3.5. Server-information 
Description 
This Configuration Option provides a way to obtain information 
about the communications server providing the remote side of the 
PPP connection. 
The nature of this option is advisory only. It is provided as a 
means of improving an end system’s ability to provide a simple 


user interface. 


A summary of the Server-Information Option format is shown below. 
The fields are transmitted from left to right. 
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0 1 2 3 

012345678901234567890123456789021 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type | Length | Server-class 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Server-implementation-id | 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Server-name 
-+-+-+-+-+-+-+-+-+-+-+-+ 


+— + — + — + 


Type 


Server-class 

The Server-class field is two octets and indicates the class of 

the communication server providing the remote end of the PPP 

connection. 

Initial values are assigned as follows: 

Value Class 

1 AppleTalk PPP Dial-in server. 

The server-implementation-id is a four byte version 
id, with the first byte defined as the major 
version number (1-255) and the second byte defined 


as the minor version number (1-255). 


The third and fourth bytes are undefined and should 
be zero. 


2 Generic AppleTalk PPP implementation. 


The server-implementation-id is undefined and 
vendor specific. 


3 Both dial-in server and router 
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Server-implementation-id 


The Server-implementation-id field is four octets and indicates 
the version of the communication server providing the remote end 
of the PPP connection. 


Server-name 


This optional field contains the "AppleTalk ASCII" name of the 
server. The character codes used in "AppleTalk ASCII" are defined 
in [3], appendix D, "Character codes". The length of the name is 
bounded by the option length. 


3.6. Zone-Information 
Description 


This Configuration Option provides a way to obtain information 
about the AppleTalk zone used for the PPP connection. 


The nature of this option is advisory only. It is provided as a 
means of improving the end system’s ability to provide a simple 
user interface. 


A summary of the Zone-Information Option format is shown below. The 
fields are transmitted from left to right. 


0 1 2 3 
0123456789012345678°9012345678<9021 
Hato to toto tatatat otto toto tatatatitototo to tatatatititotetetetatat 

| Type | Length | Zone-name... 
foto to toto tatatitoto toto to tatatatititoto ta tatatatititetotetetatat 


Type 


Zone-name 


This field contains the "AppleTalk ASCII" zone name in which the 
server resides. The character codes used in "AppleTalk ASCII" are 
defined in [3], appendix D, "Character codes". The length of the 
name is bounded by the option length. 
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3.7. Default—Router-Address 


Description 


This Configuration Option provides a way to obtain information 
about a "default" Appletalk router which may be used to obtain 
network information such as zone names. It is provided as a means 
of obtaining the address of a router in the case both sides of the 
link are end systems. 


Any AppleTalk RTMP packets received should supercede information 
negotiated in this option. 


By default, no default router is present. 


A summary of the Default-Router-Address Option format is shown below. 
The fields are transmitted from left to right. 


0 1 2 3 
O123 45 6783 9 012345678 90 1234-5 678 9 0-1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


| Type | Length | Reserved | AT-Net 
+-+-+-+-+-+-+-+-+-++ +H 
| AT-Net | AT-Node | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


Length 


Reserved 


This octet is reserved and MUST be set to zero on transmission and 
ignored on reception. 


AT-Net 
The two octet AT-Net is the AppleTalk network number of the 
default router. This two octet quantity represents a 16 bit 


unsigned number sent in "network byte order" (most significant 
octet first). 
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A. 


AT-Node 


The one octet AT-Node is the AppleTalk node ID of the default 
router. 


ATCP Recommended Options 


The ATCP is designed to support three different modes of operation. 
Each mode places constraints on the configuration options used and 
the values negotiated. 


The options for server information, zone information and default 

router address are "informational" options provided by one end of the 
connection and are not intended to be negotiated. These options are 
provided to support a higher level of service to dial-in end systems. 


The options which SHOULD be negotiated in each case are outlined 
below. Any option not listed may be rejected. 


End System to Intermediate System - "dial-in" 


This mode of operation is intended to support end system dial-in. 


AppleTalk-Address (required) 

Routing-Protocol (required, no routing protocol) 
Suppress-Broadcasts (optional) 

AT-Compression-Protocol (optional) 

Server-information (optional, request from end system) 


NP WNE 
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Intermediate system to Intermediate system - with network number 


This mode of operation is intended to support WAN-to-WAN, i.e., 
router to router, connections where the link is configured with a 
network number. 


1 AppleTalk-Address (required, nets must be zero or equal) 
2 Routing-Protocol (optional) 
3 Suppress-Broadcasts (optional) 


Intermediate system to Intermediate system - without network number 


This mode of operation is intended to support WAN-to-WAN, i.e., 
router to router, connections where the link is not configured with a 
network number. Routers in this mode are referred to as "half- 
routers" in [3]. 


1 AppleTalk-Address (optional, nets & nodes MUST be zero) 

2 Routing-Protocol (optional) 

3 Suppress-Broadcasts (optional, suppress all broadcasts) 
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